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Abstract 

Application development in the Internet of Things (IoT) is challenging because it involves dealing with a wide range of 
related issues such as lack of separation of concerns, and lack of high-level of abstractions to address both the large scale 
and heterogeneity. Moreover, stakeholders involved in the application development have to address issues that can be 
attributed to different life-cycles phases, when developing applications. First, the application logic has to be analyzed 
and then separated into a set of distributed tasks for an underlying network. Then, the tasks have to be implemented 
for the specific hardware. Apart from handling these issues, they have to deal with other aspects of life-cycle such as 
changes in application requirements and deployed devices. 

Several approaches have been proposed in the closely related fields of wireless sensor network, ubiquitous and pervasive 
computing, and software engineering in general to address the above challenges. However, existing approaches only 
cover limited subsets of the above mentioned challenges when applied to the IoT. This paper proposes an integrated 
approach for addressing the above mentioned challenges. The main contributions of this paper are: (1) a development 
methodology that separates IoT application development into different concerns and provides a conceptual framework 
to develop an application, (2) a development framework that implements the development methodology to support 
actions of stakeholders. The development framework provides a set of modeling languages to specify each development 
concern and abstracts the scale and heterogeneity related complexity. It integrates code generation, task-mapping, and 
linking techniques to provide automation. Code generation supports the application development phase by producing 
a programming framework that allows stakeholders to focus on the application logic, while our mapping and linking 
techniques together support the deployment phase by producing device-specific code to result in a distributed system 
collaboratively hosted by individual devices. Our evaluation based on two realistic scenarios shows that the use of our 
approach improves the productivity of stakeholders involved in the application development. 


1. Introduction 

The recent technological advances have been fueling a 
tremendous growth in a number of smart objects [65j p. 3] 
such as temperature sensors, smoke detectors, fire alarms, 
parking space controllers. They can sense the physical 
world by obtaining information from sensors, affect the 
physical world by triggering actions using actuators, en¬ 
gage users by interacting with them whenever necessary, 
and process captured data and communicate it to outside 
world. In the Internet of Things pm, smart objects (or 
“things”) acquire intelligence thanks to the fact that they 
can communicate with each other and cooperate with their 
neighbors to reach a common goal [2]. For example, a 
building interacts with its residents and surrounding build¬ 
ings in case of fire for safety and security of residents, of¬ 
fices adjust themselves automatically accordingly to user 
preferences while minimizing energy consumption, or traf¬ 
fic signals control in-flow of vehicles according to the cur¬ 
rent highway status m- 
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As evident above, IoT applications will involve inter¬ 
actions among large numbers of disparate devices, many 
of them directly interacting with their physical surround¬ 
ings. An important challenge that needs to be addressed 
in the IoT, therefore, is to enable the rapid development of 
IoT applications with minimal effort by the various stake¬ 
holder^] involved in the process. Similar challenges have 
already been addressed in the closely related fields of Wire¬ 
less Sensor Networks (WSNs) [65j p. 11] and ubiquitous 
and pervasive computing [65j p. 7], regarded as precur¬ 
sors to the modern day IoT. While the main challenge in 
the former is the large scale - hundreds to thousands of 
largely similar devices, the primary concern in the latter 
has been the heterogeneity of devices and the major role 
that the user’s own interaction with these devices plays in 
these systems (cf. the classic “smart home” scenario where 
a user controls lights and receives notifications from his re¬ 
frigerator and toaster.). It is the goal of our work to enable 


1 Throughout this paper, we use the term stakeholders as used 
in software engineering to mean - people, who are involved in the 
application development. Examples of stakeholders defined in m 
are software designer, developer, domain expert, technologist, etc. 


Preprint submitted to Journal of Systems and Software 


January 22, 2015 






the development of such applications. In the following, we 
discuss one of such applications. 

1.1. Application example 

We consider a hypothetical building system utilized by 
a company. This building system might consist of sev¬ 
eral buildings, with each building in turn consisting of one 
or more floors, each with several rooms. It may consist 
of a large number of heterogeneous devices equipped with 
sensors, actuators, storage, user interfaces. Figure [l] de¬ 
scribes the building automation domain with various de¬ 
vices. Many applications can be developed using these 
devices, one of which we discuss below. 

Smart building application. To accommodate the mo¬ 
bile worker’s preference in the reserved room, a database is 
used to keep the profile of each worker, including his pre¬ 
ferred lighting and temperature level. A badge reader in 
the room detects the worker’s entry event and queries the 
database for the worker’s preference. Based on this, the 
thresholds used by the room’s devices are updated. To 
reduce electricity waste when a person leaves the room, 
detected by badge disappeared event, lighting and heating 
level are automatically set to the lowest level; all accord¬ 
ing to the building’s policy. The system may also include 
user interfaces that allow a late worker to control heater 
of his room and request the profile database to get his 
lighting and temperature preferences. Moreover, the sys¬ 
tem generates the current status (e.g., temperature, energy 
consumption) of each room, which is then aggregated and 
used to determine the current status of each floor and, 
in turn, the entire building. A monitor installed at the 
building entrance presents the information to the building 
operator for situational awareness. 



Figure 1 — A cluster of multi-floored buildings with deployed 
devices with (1) temperature sensor, (2) heater, (3) badge 
reader, (4) badge, (5) alarm, (6) smoke detector, (7) sprinkler, 
(8) light, (9) data storage, and (10) monitor. 


1.2. IoT application development challenges 
This section reviews the application development chal¬ 
lenges as gleaned from our analysis of applications such as 
the one discussed in the previous section. The challenges 
we address in this work are as follows: 

Lack of division of roles . IoT application development 
is a multi-disciplined process where knowledge from mul¬ 
tiple concerns intersects. Traditional IoT application de¬ 
velopment assumes that the individuals involved in the 
application development have similar skills. This is in 
clear conflict with the varied set of skills required during 
the process, including domain expertise (e.g., the smart 
building application reason in terms of rooms and floors, 
the smart city applications are expressed in terms of sec¬ 
tors.), deployment-specific knowledge (e.g., understanding 
of the specific target area where the application is to be 
deployed, mapping of processing components to devices in 
the target deployment), application design and implemen¬ 
tation knowledge, and platform-specific knowledge (e.g., 
Android-specific APIs to get data from sensors, vendor- 
specific database such as MySQL), a challenge recognized 
by recent works such as mm- 

Heterogeneity . IoT applications execute on a network 
consisting of heterogeneous devices in terms of types (e.g., 
sensing, actuating, storage, and user interface devices), in¬ 
teraction modes (e.g. Publish/Subscribe (21], Request/Re- 
sponse [3], Command pQ), as well as different plat¬ 
forms (e.g., Android mobile OS, Java SE on laptops). The 
heterogeneity largely spreads into the application code and 
makes the portability of code to a different deployment dif¬ 
ficult. 

Scale . As mentioned above, IoT applications execute on 
distributed systems consisting of hundreds to thousands of 
devices, involving the coordination of their activities (e.g., 
temperature values are computed at per-room and then 
per-floor levels to calculate an average temperature value 
of a building). Requiring the ability of reasoning at such 
levels of scale is impractical in general, as has been largely 
the view in the WSN community. 

Different life cycle phases . Stakeholders have to ad¬ 
dress issues that are attributed to different life cycles 
phases,including development, deployment, and mainte¬ 
nance [7 . At the development phase, the application 
logic has to be analyzed and separated into a set of dis¬ 
tributed tasks for the underlying network consisting of a 
large number of heterogeneous entities. Then, the tasks 
have to be implemented for the specific platform of a de¬ 
vice. At the deployment phase, the application logic 
has to be deployed onto a large number of devices. Apart 
from handling these issues, stakeholders have to keep in 
mind evolution issues both in the development (change in 
functionality of an application such as the smart building 
application is extended by including fire detection func¬ 
tionality) and deployment phase (e.g. adding/removing 
devices in deployment scenarios such as more temperature 
sensors are added to sense accurate temperature values in 


2 









































the building) at the maintenance phase. Manual ef¬ 
fort in all above three phases for hundreds to thousands of 
heterogeneous devices is a time-consuming and error-prone 
process. 

In order to address the above mentioned challenges, var¬ 
ious approaches have been proposed (for a detailed discus¬ 
sion of various systems available for application develop¬ 
ment, refer Section [ 5 ]). One of the approach is node-centric 
programming mmm- It allows for the development 
of extremely efficient systems based on complete control 
over individual devices. However, it is not easy to use for 
IoT applications due to the large size and heterogeneity 
of systems. In order to address node-centric programming 
limitation, various macroprogramming systems gam have 
been proposed. However, most of macroprogramming sys¬ 
tems largely focus on development phase while ignoring 
the fact that it represents a tiny fraction of the applica¬ 
tion development life-cycle. The lack of a software en¬ 
gineering methodology to support the entire application 
development life-cycle commonly results in highly diffi¬ 
cult to maintain, reuse, and platform-dependent design, 
which can be tackled by the model-driven approach. To 
address the limitations of macroprogramming systems, ap¬ 
proaches based on model-driven design (MDD) have been 
proposed [S3 m SOI EZJ- Major benefits came from the 
basic idea that by separating different concerns of a system 
at a certain level of abstraction, and by providing trans¬ 
formation engines to convert these abstractions to a tar¬ 
get code, productivity ( e.g ., reusability, maintainability) 
in the application development process can be improved. 

1.3. Contributions 

Our aim is to make IoT application development easy 
for stakeholders as is the case in software engineering in 
general, by taking inspiration from the MDD approach and 
building upon work in sensor network macroprogramming. 
We achieve this aim by separating IoT application develop¬ 
ment into different concerns and integrating a set of high- 
level language^] to specify them. We provide automation 
techniques at different phases of IoT application develop¬ 
ment to reduce development effort. We now present these 
contributions in detail described below: 

Development methodology. We propose a development 
methodology that defines a precise sequence of steps to be 
followed to develop IoT applications, thus facilitating IoT 
application development. These steps are separated into 
four concerns, namely, domain, functional, deployment, 
and platform. This separation allows stakeholders to deal 
with them individually and reuse them across applications. 
Each concern is matched with a precise stakeholder accord¬ 
ing to skills. The clear identification of expectations and 


2 Please note that high-level languages (e.g., AADL, EAST-ADL, 
SysML, etc.) for IoT have been investigated at length in the do¬ 
mains of pervasive/ubiquitous computing and wireless sensor net¬ 
work. However, their integration to our development framework in 
an appropriate way is our contribution. 


specialized skills of each type of stakeholders helps them 
to play their part effectively. 

Development framework. To support the actions of 
each stakeholder, the development methodology is imple¬ 
mented as a concrete development framework]^] It provides 
a set of modeling languages, each named after “Srijan”]^] 
and offers automation techniques at different phases of IoT 
application development, including the following: 

• A set of modeling languages. To aid stake¬ 
holders, the development framework integrates three 
modeling languages that abstract the scale and 
heterogeneity-related complexity: (1) Srijan Vocabu¬ 
lary Language (SVL) to describe domain-specific fea¬ 
tures of an IoT application, (2) Srijan Architecture 
Language (SAL) to describe application-specific func¬ 
tionality of an IoT application, (3) Srijan Deployment 
Language (SDL) to describe deployment-specific fea¬ 
tures consisting information about a physical environ¬ 
ment where devices are deployed. 

• Automation techniques. The development frame¬ 
work is supported by code-generation, task-mapping, 
and linking techniques. These three techniques to¬ 
gether provide automation at various phases of IoT 
application development. Code generation supports 
the application development phase by producing a 
programming framework that reduces the effort in 
specifying the details of the components of an IoT 
application. Mapping and linking together support 
the deployment phase by producing device-specific 
code to result in a distributed system collaboratively 
hosted by individual devices. 

Our work on the above is supported at the lower layers 
by a middleware that enables delivery of messages across 
physical regions, thus enabling our abstractions for man¬ 
aging large scales in the Internet of Things. 

Outline. The remainder of this paper is organized as 
follows: Section [2] presents our development methodology 
and its development framework. This includes details of on 
modeling languages, automation techniques, and our ap¬ 
proach for handling evolutions. Section [3] presents an im¬ 
plementation of our development framework. We present 
tools, technologies, and programming languages used to 
implement this development framework. Section [4] evalu¬ 
ates the development framework in a quantitative manner. 
Section [5] explores state of the art approaches for develop¬ 
ing IoT applications. Section [6] summarizes this paper and 
Section [7] describes briefly some future directions of this 
work. 


3 It includes support programs, code libraries, high-level languages 
or other software that help stakeholders to develop and glue together 
different components of a software product. 

4 Srijan is the Sanskrit word for “creation”. 
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2. Our approach to IoT application development 


Applying separation of concerns design principal from 
software engineering, we break the identified concepts 
and associations among them into different concerns rep¬ 
resented in Conceptual model [48 , described in Sec¬ 
tion 2.1 The identified concepts are linked together into 
a well-defined and structured methodology, described in 
Section |2.2| We implement the proposed development 
methodology as a concrete development framework jm 


ESJ EH HU, presented in Section [2i3| 


2.1. Conceptual model 

A conceptual model often serves as a base of knowledge 
about a problem area [23] . It represents the concepts as 
well as the associations among them and also attempts to 
clarify the meaning of various terms. Taking inspiration 
from previous efforts mmm, we have identified four 
major concerns for IoT application development. Figure [2] 
illustrates the concepts and their associations along with 
these four separate concerns: (1) domain-specific concepts, 
(2) functionality-specific concepts, (3) deployment-specific 
concepts, and (4) platform-specific concepts. 


2.1.1. Domain-specific concepts 

The concepts that fall into this category are specific to 
a target application domain (e.g., building automation, 
transport, etc.). For example, the building automation 
domain is reasoned in terms of rooms and floors, while the 
transport domain is expressed in terms of highway sec¬ 
tors. Furthermore, each domain has a set of entities of 
interest (e.g., average temperature of a building, smoke 
presence in a room), which are observed and controlled by 
sensors and actuators respectively. Storages store informa¬ 
tion about entities of interest, and user interfaces enable 
users to interact with entities of interest (e.g., receiving 
notification in case of fire in a building, controlling the 
temperature of a room). We describe these concepts in 
detail below: 

• An Entity of Interest (Eol) is an object (e.g., room, 
book, plant), including attributes that describe it, and 
its state that is relevant from a user or an application 
perspective j31j p. 1]. The entity of interest has an 
observable property called phenomenon. Typical ex¬ 
amples are the temperature value of a room and a tag 
ID. 

• A resource is a conceptual representation of a sen¬ 
sor, an actuator, a storage, or a user interface. We 
consider the following types of resources: 

— A sensor has the ability to detect changes in the 
environment. Thermometer and tag readers are 
examples of sensors. The sensor observes a phe¬ 
nomenon of an Eol. For instance, a temperature 
sensor observes the temperature phenomenon of 
a room. 


— An actuator makes changes in the environment 
through an action. Heating or cooling elements, 
speakers, lights are examples of actuators. The 
actuator affects a phenomenon of an Eol by per¬ 
forming actions. For instance, a heater is set to 
control a temperature level of a room. 

— A storage has the ability of storing data in a 
persistent manner. The storage stores informa¬ 
tion about a phenomenon of an Eol. For instance, 
a database server stores information about an 
employee’s temperature preference. 

— A user interface represents tasks available to 
users to interact with entities of interest. For the 
building automation domain, a task could be re¬ 
ceiving a fire notification in case of emergency or 
controlling a heater according to a temperature 
preference. 

• A device is located in a region [64]. The region is used 
to specify the location of a device. In the building 
automation domain, a region (or location) of a device 
can be expressed in terms of building, room, and floor 

IDs. 

2.1.2. Functionality-specific concepts 

The concepts that fall into this category describe compu¬ 
tational elements of an application and interactions among 
them. A computational element is a type of software com¬ 
ponent, which is an architectural entity that (1) encapsu¬ 
lates a subset of the system’s functionality and/or data, 
(2) restricts access to that subset via an explicitly defined 
interface [63, p. 69]. We use the term application logic 
to refer a functionality of a software component. An ex¬ 
ample of the application logic is to open a window when 
the average temperature value of a room is greater than 
30° C. 

The conceptual model contains the following 
functionality-specific software component, a compu¬ 
tational service, which is a type of software component 
that consumes one or more units of information as inputs, 
processes it, and generates an output. An output could be 
data message that is consumed by others or a command 
message that triggers an action of an actuator. A com¬ 
putational service is a representation of the processing 
element in an application. 

A software component communicates-with other soft¬ 
ware components to exchange data or control. These in¬ 
teractions might contain instances of various interaction 
modes such as request-response, publish-subscribe, and 
command. Note that this is in principle an instance of 
the component-port-connector architecture used in soft¬ 
ware engineering. 

2.1.3. Deployment-specific concepts 

The concepts that fall into this category describe infor¬ 
mation about devices. Each device hosts zero or more 
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Figure 2 — Conceptual model for IoT applications 


resources. For example, a device could host resources such 
as a temperature sensor to sense, a heater to control a tem¬ 
perature level, a monitor to display a temperature value, 
a storage to store temperature readings, etc. Each device 
is located-in regions. For instance, a device is located- 
in room^l of floor# 12 in building# 14. We consider the 
following definition of a device: 

• A device is an entity that provides resources the abil¬ 
ity of interacting with other devices. Mobile phones, 
and personal computers are examples of devices. 

2.1.4- Platform-specific concepts 

The concepts that fall into this category are computer 
programs that act as a (operating system-specific) trans¬ 
lator between a hardware device and an application. We 
identify the following platform-specific concepts: 

• A sensor driver is a type of software component that 
operates on a sensor attached to a device. It accesses 
data observed by the sensor and generates the mean¬ 
ingful data that can be used by other software com¬ 
ponents. For instance, a temperature sensor driver 
generates temperature values and its meta-data such 


as unit of measurement, time of sensing. Another soft¬ 
ware component takes this temperature data as input 
and calculates the average temperature of the room. 

• An actuator driver is a type of software compo¬ 
nent that controls an actuator attached to a device. 
It translates a command from other software compo¬ 
nents and actuates the actuator appropriately. For 
instance, a heater driver translates a command “turn 
the heater on” to regulate the temperature level. 

• A storage service is a type of software component 
that provides a read and write access to a storage. 
A storage service provides access to the storage. 
Other software components access data from the stor¬ 
age by requesting the storage service. For instance, 
MySQL storage service provides access to a database 
server. 

• An end-user application is a type of software com¬ 
ponent that is designed to help a user to perform 
tasks (e.g., receiving notifications, submitting infor¬ 
mation). It provides access to available tasks. For 
instance, in the smart building application a user 
could provide his temperature preferences using an 
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application installed on his smart phone. 


Role Skills 


Responsibilities 


The next section presents a development methodology 
that links the above four concerns and provides a concep¬ 
tual framework to develop IoT applications. 

2.2. A development methodology 

To make IoT application development easy, stakehold¬ 
ers should be provided a structured and well-defined ap¬ 
plication development process (referred to as develop¬ 
ment methodology ). This section presents a development 
methodology that integrates different development con¬ 
cerns discussed in Section |2.1| and provides a conceptual 
framework for IoT application development. In addition 
to this, it assigns a precise role to each stakeholder com¬ 
mensurate with his skills and responsibilities. 

As stated in Section [L2} IoT application development is 
a multi-disciplined process where knowledge from multiple 
concerns intersects. So far, IoT application development 
assumes that the individuals have similar skills. While this 
may be true for simple/small applications for single-use 
deployments, as the IoT gains wide acceptance, the need 
for sound software engineering approaches to adequately 
manage the development of complex applications arises. 

Taking inspiration from ideas proposed in the 4+1 view 
model of software architecture [36], collaboration model 
for smart spaces 0 , and tool-based methodology for per¬ 
vasive computing [12,, we propose a development method¬ 
ology that provides a conceptual framework to develop an 
IoT application (detailed in Figure [3]). The development 
methodology divides the responsibilities of stakeholders 
into five distinct roles —domain expert, software designer, 
application developer, device developer, and network man¬ 
ager. Note that although these roles have been discussed in 
the software engineering literature in general, e.g., domain 
expert and software designer in [B3J p. 657], application 
developer (T2J p. 3], their clear identification for IoT appli¬ 
cations is largely missing. Due to the existence of various, 
slightly varying, definitions in literature, we summarize 
the skills and responsibilities of the various stakeholders 
in Table Q] 

An application corresponds to a specific application do¬ 
main (e.g., building automation, health-care, transport) 
consisting of domain-specific concepts. Keeping this in 
mind, we separate the domain concern from other con¬ 
cerns (see Figure [3j stage 1). The main advantage of this 
separation is that domain-specific knowledge can be made 
available to stakeholders and reused across applications of 
a same application domain. 

IoT applications closely interact with the physical world. 
Consequently, changes in either of them have a direct in¬ 
fluence on the other. The changes could be technological 
advances with new software features, a change in function¬ 
ality of an application, a change in distribution of devices, 
and adding or replacing devices. Considering this aspect, 
we separate IoT application development into the plat¬ 
form, functional, and deployment concern at the second 


Domain Understands domain Specify the vocabulary 

expert concepts, including the of an application do- 

data types produced by main to be used by 
the sensors, consumed applications in the do- 
by actuators, accessed main, 
from storages, user’s 
interactions, and how 
the system is divided 
into regions. 

Software de- Software architecture Define the structure of 

signer concepts, including an IoT application by 

the proper use of in- specifying the software 

teraction modes such components and their 

as publish-subscribe, generate, consume, and 

command, and request- command relationships, 

response for use in the 
application. 

Application Skilled in algorithm de- Develop the application 

developer sign and use of pro- logic of the computa- 

gramming languages. tional services in the ap¬ 
plication. 

Device devel- Deep understanding of Write drivers for the 

oper the inputs/outputs, and sensors, actuators, stor- 

protocols of the individ- ages, and end-user ap- 

ual devices. plications used in the 

domain. 

Network Deep understanding of Install the application 

manager the specific target area on the system at hand; 

where the application is this process may involve 

to be deployed. the generation of bina¬ 

ries or bytecode, and 
configuring middleware. 


Table 1 — Roles in IoT application development 


stage (see Figure |3j stage 2). Thus, stakeholders can deal 
with them individually and reuse them across applications. 
The final stage combines and packs the code generated by 
the second stage into packages that be deployed on de¬ 
vices (see Figure |3j stage 3). 


2.3. Development framework 

To support actions of stakeholders, the development 
methodology discussed in Section |2.2| is implemented as 
a concrete development framework. This section presents 
this development framework that provides a set of mod¬ 
eling languages, each named after Srijan , and offers au¬ 
tomation techniques at different phases of IoT application 
development for the respective concerns. 


2.3.1. Domain concern 

This concern is related to domain-specific concepts of an 
IoT application. It consists of the following steps: 

• Specifying domain vocabulary. The domain ex¬ 
pert specifies a domain vocabulary (step ® in Fig¬ 
ure [3]) using the Srijan Vocabulary Language (SVL). 
The vocabulary includes specification of resources, 
which are responsible for interacting with entities of 
interest. In the vocabulary, resources are specified 
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in a high-level manner to abstract low-level details 
from the domain expert. Moreover, the vocabulary 
includes definitions of regions that define spatial par¬ 
titions (e.g., room, floor, building) of a system. 

• Compiling vocabulary specification. Leveraging 
the vocabulary, the development framework gener¬ 
ates (step (2) in Figure [3|: (1) a vocabulary framework 
to aid the device developer, (2) a customized architec¬ 
ture grammar according to the vocabulary to aid the 
software designer, and (3) a customized deployment 
grammar according to the vocabulary to aid the net¬ 
work manager. The key advantage of this customiza¬ 
tion is that the domain-specific concepts defined in 
the vocabulary are made available to other stakehold¬ 
ers and can be reused across applications of the same 
application domain. 

2.3.2. Functional concern 

This concern is related to functionality-specific concepts 
of an IoT application. It consists of the following steps: 

• Specifying application architecture. Using a cus¬ 
tomized architecture grammar, the software designer 
specifies an application architecture (step (3) in Fig¬ 
ure [3]) using the Srijan Architecture Language (SAL). 


SAL is an architecture description language (ADL) 
designed for specifying computational services and 
their interactions with other software components. To 
facilitate scalable operations within IoT applications, 
SAL offers scope constructs. These constructs allow 
the software designer to group devices based on their 
spatial relationship to form a cluster (e.g., “devices 
are in room#l”) and to place a cluster head to receive 
and process data from that cluster. The grouping and 
cluster head mechanism can be recursively applied to 
form a hierarchical clustering that facilitates the scal¬ 
able operations within IoT applications. 

• Compiling architecture specification. The de¬ 
velopment framework leverages an architecture speci¬ 
fication to support the application developer (step (4) 
in Figure [3]). To describe the application logic of 
each computational service, the application developer 
is provided an architecture framework, pre-configured 
according to the architecture specification of an ap¬ 
plication, an approach similar to the one discussed 
in pT|. 

• Implementing application logic. To describe the 
application logic of each computational service, the 
application developer leverages a generated architec- 























































ture framework (step (5) in Figure [ 3 ]). It contains ab¬ 
stract classe^J corresponding to each computational 
service, that hide interaction details with other soft¬ 
ware components and allow the application developer 
to focus only on application logic. The application 
developer implements only the abstract methods of 
generated abstract classes. 

2.3.3. Deployment concern 

This concern is related to deployment-specific concepts 
of an IoT application. It consists of the following steps: 

• Specifying target deployment. Using a cus¬ 
tomized deployment grammar, the network manager 
describes a deployment specification (step (6) in Fig¬ 
ure |3| using the Srijan Deployment Language (SDL). 
The deployment specification includes the details of 
each devic^J including its regions (in terms of values 
of the regions defined in the vocabulary), resources 
hosted by devices (a subset of those defined in the 
vocabulary), and the type of the device. Ideally, the 
same IoT application could be deployed on different 
target deployments (e.g., the same inventory tracking 
application can be deployed in different warehouses). 
This requirement is dictated by separating a deploy¬ 
ment specification from other specifications. 

• Mapping. The mapper produces a mapping from 
a set of computational services to a set of de¬ 
vices (step (7) in Figure [3|. It takes as input a set 
of placement rules of computational services from an 
architecture specification and a set of devices defined 
in a deployment specification. The mapper decides 
devices where each computational service will be de¬ 
ployed. 

2.3.4■ Platform concern 

This concern is related to platform-specific concepts of 
an IoT application. It consists of the following step: 

• Implementing device drivers. Leveraging the vo¬ 
cabulary, our system generates a vocabulary frame¬ 
work to aid the device developer (step (8) in Fig¬ 
ure [ 3 ]). The vocabulary framework contains interfaces 
and concrete classes corresponding to resources de¬ 
fined in the vocabulary. The concrete classes contain 
concrete methods for interacting with other software 
components and platform-specific device drivers. The 
interfaces are implemented by the device developer to 
write platform-specific device drivers. 


5 We assume that the application developer uses an object- 
oriented language. 

6 Our work excludes low-end computing devices (e.g., SunSpoT, 
TelosB, Tmote Sky, etc.). We believe this is a reasonable assump¬ 
tion because technological advances in embedded system result into 
devices with more and more computational power and memory. 


2.3.5. Linking 

The linker combines and packs code generated by vari¬ 
ous stages into packages that can be deployed on devices. 
It merges generated architecture framework, application 
logic, mapping files, device drivers, and vocabulary frame¬ 
work (step (9) in Figure [ 3 ]). This stage supports the appli¬ 
cation deployment phase by producing device-specific code 
to result in a distributed software system collaboratively 
hosted by individual devices, thus providing automation 
at the deployment phas^] 

2.3.6. Handling evolution 

Evolution is an important aspect in IoT application de¬ 
velopment where new resources and computational ser¬ 
vices are added, removed, or extended. To deal with these 
changes, our development framework separates IoT appli¬ 
cation development into different concerns and allows an 
iterative development m for these concerns. 

This next section provides the details of our approach 
including three modeling languages (SVL, SAL, and SDL), 
programming frameworks to aid stakeholders, and an ap¬ 
proach for handling evolution. This section refers to the 
building automation domain discussed in Section 0 for 
describing examples. 

2.4■ Specifying domain concern with the SVL 

The domain concern describes an application domain of 
an IoT application. The domain expert specifies it using 
SVL. A vocabulary includes specification of resources that 
are responsible for interacting with entities of interest, in¬ 
cluding sensors, actuators, storages, and user interfaces. 
Moreover, it includes region definitions specific to the ap¬ 
plication domain. We now present SVL for describing the 
domain concern. 

SVL is designed to enable the domain expert to describe 
a domain vocabulary domain. It offers constructs to spec¬ 
ify concepts that interact with entities of interest. Fig¬ 
ure [4] illustrates domain-specific concepts (defined in the 
conceptual model Figure [ 2 ]) that can be specified using 
SVL. These concepts can be described as V = (V,'D,TV). 
V represents the set of regions, V represents the set of 
data structure, and 7 Z represents the set of resources. We 
describe these concepts in detail as follows: 

regions (V). It represents the set of regions that are 
used to specify locations of devices. A region definition 
includes a region label and region type. For example, the 
building automation is reasoned in terms of rooms and 
floors (considered as region labels), while the transport 
domain is expressed in terms of highway sectors. Each 
room or floor in a building may be annotated with an 
integer value (e.g. room:l interprets as room number 1) 
considered as region type. This construct is declared using 


7 We assume that a middleware is already installed on the deployed 
devices. The installed middleware enables inter-device communica¬ 
tion among devices. 
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Figure 4 — Class diagram of domain-specific concepts 


the regions keyword. Listing [T| (lines [T]|4| ) shows region 
definitions for the building automation domain. 


data structures (V). Each resource is characterized by 
types of information it generates or consumes. A set of in¬ 
formation is defined using the structs keyword (Listing [l] 
line [5]). For instance, a temperature sensor may generate a 
temperature value and unit of measurement (e.g., Celsius 
or Fahrenheit). This information is defined as TempStruct 
and its two fields (Listing [l] lines 9pT). 


resources (TZ). It defines resources that might be at¬ 
tached with devices, including sensors, actuators, stor¬ 
ages, or user interfaces. It is defined as 7 Z = 
(TZ sens or 1 TZ actuator->TZ storage ->TZ u i) - TZ se nsor represents a 
set of sensors, 7 Z actU ator represents a set of actuators, 
TZstorage represents a set of storages, and R u i represents 
a set of user interfaces. We describe them in detail as 
follows: 


sensors (TZ sen sor)'- It defines a set of various types 
of sensors (e.g., temperature sensor, smoke detector). 
A set of sensors is declared using the sensors key¬ 
word (Listing [l] line 13). Sgenerate is a set of sen¬ 
sor measurements produced by 7 Z sen sor- Each sen¬ 
sor (S £ 7 Zsensor) produces one or more sensor mea¬ 
surements (op £ Sg ener ate ) along with the data-types 
specified in the data structure (V). A sensor measure¬ 
ment of each sensor is declared using the generate 
keyword (Listing [l] line [T7|) . For instance, a temper¬ 
ature sensor generates a temperature measurement of 
Tempstruct type (lines PP1> defined in data struc¬ 
tures (lines |9]|lT)). 


• actuators (TZ ac tuator)'- If defines a set of various 
types of actuatoi]^] (e.g., heater, alarm). A set of actu¬ 
ators is declared using the actuators keyword (List¬ 
ing 0 line [l8|) . A ac tion is a set of actions performed 
by 7 Zactuator- Each actuator (A £ TZactuator ) has one 
or more actions (a £ Aaction) that is declared using 


the action keyword. An action of an actuator may 
take inputs specified as parameters of an action (List¬ 
ing 0 line [ 2 T]) . For instance, a heater may has two 
actions. One is to switch off the heater and second 
is to set the heater according to a user’s temperature 
preference illustrated in Listing [l] lines mm The 
SetTemp action takes a user’s temperature preference 
shown in line [2TJ 

• storages (TZstorage)'- If defines a set of storage^] (e.g., 
user’s profile storage) that might be attached to a de¬ 
vice. A set of storages is declared using the stor¬ 
ages keyword (Listing [lj line 22). ST generate repre¬ 
sents a set of retrievals of TZ storage- A retrieval (rq £ 
ST generate) from the storage (ST £ TZstorage ) re¬ 
quires a parameter. Such a parameter is specified 
using the accessed-by keyword (Listing [l] line [24]) . 
For instance, a user’s profile is accessed from profile 
storage by his unique badge identification illustrated 
in Listing |TJ lines |23]|24| 

• user interfaces ( TZ u i ): It defines a set of tasks (e.g., 
controlling a heater, receiving notification from a fire 
alarm, or requesting preference information from a 
database server) available to users to interact with 
other entities. A set of user interfaces is declared using 
the user interfaces keyword (Listing [I] line 25). 
The user interface provides the following tasks: 


— command ( U. command) - If is a set of commands 
available to users to control actuators, repre¬ 
sented as Ueommand- A user can control an ac¬ 
tuator by triggering a command (e.g., switch 
off the heater) declared using the command key¬ 
word (Listing [l] line 27). 

— action ( U ac uon )• If is a set of actions that can 
be invoked by other entities to notify users, rep¬ 
resented as Uaction - The other resources may no¬ 
tify a user (e.g., notify the current temperature) 
by invoking an action provided by the user inter¬ 
face. The notification task is declared using the 
action keyword (Listing [l] line 28). 

— request ( Urequest)'- If is a set of request though 
which a user can request other resources for data, 
represented as U req uest - A user can retrieve data 
by requesting a resource (e.g., retrieve my tem¬ 
perature preference). This is declared using the 
request keyword (Listing [TJ line 29). 


regions : 

Building: integer; 


8 Since a deployment infrastructure may be shared among a num¬ 
ber of different IoT applications and users, it is likely that these 
applications may have actuation conflicts. This work assumes actu¬ 
ators are pre-configured which can resolve actuation conflicts. 


9 Even though IoT applications may include rich diverse set of 
storages available today on the Internet (e.g., RDBMs and noSQL 
databases, using content that is both user generated such as photos 
as well as machine generated such as sensor data), we restrict our 
work to key-value data storage services. 
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Floor : integer ; 

Room: integer ; 
struct s : 

BadgeDetectedStruct 
badgelD: string; 
timeStamp: long; 

TempStruct 

tempValue: double; 
unitOfMeasurement: string; 
resources : 

sensors : 

BadgeReader 

generate badgeDetected: 
BadgeDetectedStruct; 
TemperatureSensor 

generate tempMeasurement: TempStruct; 

actuators : 

Heater 

action Off () ; 

action SetTemp(setTemp : TempStruct); 


can be described as A v = (C). C represents a set 
of computational services. It is described as C = 


(Cgenerate•> Cconsume 5 Crequest -> ^commandi ^in—region-) Chops)- 

Cgenerate represents a set of outputs produced by 
computational services. Cconsume is a set of inputs 
consumed by computational services. The inputs could 
be data produced by other computational services or 
sensors (7 Z sensor )- C reques t represents a set of request by 
computational services to retrieve data from the stor¬ 
ages (7 Zstorage)- Command represents a set of commands 
to invoke actuators (TZactuator) or user interfaces (7 Z U i). 
Cin-region is a set of regions (7 Iregion) where com¬ 
putational services can be placed. Chops is a set of 
regions (7 Z reg ion) where computational services receive 
data. In the following, we describe these concepts in 
detail. 


storages : 

ProfileDB 

generate profile: TempStruct 

accessed-by badgelD: string; 
userinterfaces: 

EndUserGUI 

command Off () ; 

action DisplayData(displayTemp: 
TempStruct); 

request profile(badgelD); 

Listing 1 — Code snippet of the building automation domain 
using SVL. Keywords are printed in blue. 

The regions (V), data structures (£>), and resources (TZ) 
defined using SVL in the vocabulary are used to customize 
the grammar of SAL, and can be exploited by tools to 
provide support such as code completion to the software 
designer, discussed next. 



Figure 5 — Class diagram of functionality-specific concepts 


2.5. Specifying functional concern 

This concern describes computational services and how 
they interact with each other to describe functionality of 
an application. We describe the computational services 
and interactions among them using SAL (discussed in Sec¬ 
tion 2.5.1). The development framework customizes the 
SAL grammar to make domain-specific knowledge defined 
in the vocabulary available to the software designer and 
use it to generate an architecture framework. The appli¬ 
cation developer leverages this generated framework and 
implements the application logic on top of it (discussed in 
Section 12.5.21). 


2.5.1. Srijan architecture language (SAL) 

Based on a vocabulary, the SAL grammar is customized 
to enable the software designer to design an application. 
Specifically, sensors (7 l sensor ), actuators (TZ,actuator) , stor¬ 
ages (' TZstorage ), user interfaces (7 Z U i), and regions (V) de¬ 
fined in the vocabulary become possible set of values for 
certain attributes in SAL (see underlined words in List- 
ing|2]). 

Figure [5] illustrates concepts related-to a compu¬ 
tational service that can be specified using SAL. It 


consume (C consnme ) and generate ( C genera te )• These 
two concepts together define publish/subscribe interaction 
mode that provides subscribers with the ability to express 
their interest in an event, generated by a publisher, that 
matches their registered interest. A computational service 
represents the publish and subscribe using generate and 
consume concept respectively. We describe these two con¬ 
cepts in details as follows: 

• consume: It represents a set of subscriptions (or con¬ 
sumes) expressed by computational services to get 
event notifications generated by sensors (S genera te) 
defined in the vocabulary specification or other com¬ 
putational services (C genera te) defined in the architec¬ 
ture specification. Thus, C consurne can be C genera te U 
Sgenerate • A consume (c G C con sume) of a computa¬ 
tional service is expressed using the consume keyword. 
The computational service expresses its interest by an 
event name. For instance, a computational service 
RoomAvgTemp, which calculates an average tempera¬ 
ture of a room, subscribes its interest by expressing 
event name t empMe asur ement illustrated in Listing [2| 
linelU 
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generate : It represents a set of publications (or gen¬ 
erates) that are produced by computational services. 
A generate (g E C genera te ) of a computational service 
is expressed using the generate keyword. The com¬ 
putational service transforms data to be consumed by 
other computational services in accordance with the 
application needs. For instance, the computational 
service RoomAvgTemp consumes temperature measure¬ 
ments (i.e., tempMeasurement), calculates an average 
temperature of a room, and generates roomAvgTemp- 


Measurement (Listing [2j lines [7 
RoomController service (Listing 


|9b that is used by 
2j lines TTp2 ). 


request (C reques t)» It is a set of requests, issued by compu¬ 
tational services, to retrieve data from storages (7 Z st 0 rage) 
defined in the vocabulary specification. A request is a 
one-to-one synchronous interaction with a return values. 
In order to fetch data, a requester sends a request mes¬ 
sage containing an access parameter to a responder. The 
responder receives and processes the request message, ul¬ 
timately returns an appropriate message as a response. 
An access ( rq E C request ) of the computational service is 
specified using request keyword. For instance, a compu¬ 
tational service Proximity (Listing [2j line [5]), which wants 
to access user’s profile data, sends a request message con¬ 
taining profile information as an access parameter to a 
storage ProfileDB (Listing [l] line 24). 
command (C cornrnan d) • It is a set of commands, issued 
by a computational service to trigger actions provided by 
actuators (7 Z actU ator) or user interfaces (7 Z U i). So, it can 
be a subset of A ac tion U lA ac tion • The software designer 
can pass arguments to a command depend on action sig¬ 
nature provided by actuators or user interfaces. Moreover, 
he specifies a scope of command, which specifies a region 
where commands are issued. A command is specified us¬ 
ing the command keyword. An example of command invo¬ 
cation is given in line[l4|of Listing [2| The room controller 
service (i.e., roomControiler), which regulates tempera¬ 
ture, issues a SetTemp command with a preferred temper¬ 
ature as an argument (i.e., set temp) to heaters (Listing [l] 
line [ 2 T]) . 


in-region ( Ci n - reg i on ) and hops (Chops)- To facilitate 
the scalable operations within an IoT application, devices 
should be grouped to form a cluster based on their spa¬ 
tial relationship [59] (e.g., 1 “devices are in room^l”). The 
grouping could be recursively applied to form a hierar¬ 
chy of clusters. Within a cluster, a computational service 
is placed to receive and process data from its cluster of 
interest. Figure [6] shows this concept for more clarity. 
The temperature data is first routed to a local average 
temperature service (i.e., RoomAvgTemp), deployed in per 
room, then later per floor (i.e., FloorAvgTemp), and then 
ultimately routed to building average temperature service 
(i.e., BuildingAvgTemp). 

SAL offers scope constructs to define both the service 
placement ( Ci n - reg i on ) and its data interest (Chops)- The 
service placement (defined using the in-region keyword) 



Figure 6 — Clustering in the smart building application. The 
device with temperature sensor is numbered as [1]. 


is used to govern a placement of computational service in 
a cluster. The service placement can be in regions defined 
in a vocabulary specification. So, it is a subset of V. 

The data interest of a computational service is used 
to define a cluster from which the computational service 
wants to receive data. The data interest can be in re¬ 
gions defined in the vocabulary specification. So, it is 
a subset of V. It is defined using the hops keyword. 
The syntax of this keyword is hops: radius :unit of ra¬ 
dius. Radius is an integer value. The unit of radius is 
a cluster value. For example, if a computational service 
FloorAvgTemp deployed on floor number 12 has a data in¬ 
terest hops: i: Floor, then it wants data from all floors 
starting from 12-th floor to (12+i)-th floor, and all floors 
starting from 12-th floor to (12-i)-th floor . 

Figure [7] shows the architecture of the smart building 
application. Computational services are fueled by sensing 
components. They process inputs data and take appropri¬ 
ate decisions by triggering actuators. We illustrate SAL 
by examining a code snippet in Listing [2} which describes 
a part of Figure [7| This code snippet revolves around 
the actions of the Proximity service (Listing [ 2 J lines [ 2 ]- 
[6]), which coordinates events from the BadgeReader with 
the content of ProfileDB storage service. To do so, the 
Proximity composes information from two sources, one 
for badge events (i.e., badge detection), and one for re¬ 
questing the user’s temperature profile from ProfileDB, 
expressed using the request keyword (Listing [2j line [5]). 
Input data is declared using the consume keyword that 
takes source name and data interest of a computational 
service from logical region (Listing [2j line [4]). The decla¬ 
ration of hops: 0: room indicates that the computational 
service is interested in consuming badge events of the cur¬ 
rent room. The Proximity service is in charge of manag¬ 
ing badge events of room. Therefore, we need Proximity 
service to be partitioned per room using in-region:room 
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Figure 7 — Architecture of the smart building application, 
similar to work in m- 


(Listing [2j line [6]). The outputs of the Proximity and 
RoomAvgTemp are consumed by the RoomController ser¬ 
vice (Listing [2j lines Tl]p~5 ). This service is responsible 
for taking decisions that are carried out by invoking com¬ 
mands declared using the command keyword (Listing [2j 
line fl4 ). 


computationalServices: 

Proximity 

generate tempPref: UserTempPrefStruct; 
consume badgeDetected from hops:0: Room; 
request profile ( 
badgelD ); 
in-region: Room ; 

RoomAvgTemp 

generate roomAvgTempMeasurement:TempStruct; 
consume tempMeasurement from hops:0: 

Room ; 

in-region: Room ; 

RoomController 

consume roomAvgTempMeasurement from hops:0: 
Room ; 

consume tempPref from hops:0: Room ; 
command SetTemp ( setTemp ) to hops:0: Room ; 
in-region: Room ; 


framework contains abstract classes corresponding to the 
architecture specification. The abstract classes include two 
types of methods: (1) concrete methods to interact with 
other components transparently through the middleware 
and (2) abstract methods that allow the application de¬ 
veloper to program the application logic. The application 
developer implements each abstract method of generated 
abstract class. The key advantage of this framework is 
that a framework structure remains uniform. Therefore, 
the application developer have to know only locations of 
abstract methods where they have to specify the applica¬ 
tion logic. 

Abstract methods. For each input declared by a com¬ 
putational service, an abstract method is generated for 
receiving data. This abstract method is then implemented 
by the application developer. The class diagram in Fig¬ 
ure [8] illustrates this concept. This class diagram uses 
italicized text for the Proximity class, which represents 
an abstract class, and onNewbadgeDetectedO that rep¬ 
resents abstract method. Then, it is implemented in the 
SimpleProximity class. 

Listing [3] and [4] show Java code corresponding to the 
class diagram illustrated in Figure [8j From the badgeDe- 
tected input of the Proximity declaration in the architec¬ 
ture specification (Listing|2j lines |2]|6| ), the onNewbadgeDe¬ 
tectedO abstract method is generated (Listing|3j line[l6|). 
This method is implemented by the application developer. 
Listing [4] illustrates the implementation of onNewbadgeDe- 
tectedO. It updates a user’s temperature preference and 
sets it using settempPref () method. 



Figure 8 — Class diagram represents (1) the abstract class 
Proximity with its abstract method onNewbadgeDetectedO il¬ 
lustrated in italicized text, and (2) the concrete implementa¬ 
tion of onNewbadgeDetectedO method is the SimpleProximity 

class. 


Listing 2 — A code snippet of the architecture specification 
for the smart building application using SAL. The language 
keywords are printed in blue, while the keywords derived from 
vocabulary are printed underlined . 

2.5.2. Implementing application logic 

Leveraging the architecture specification, we generate a 
framework to aid the application developer. The generated 


public abstract class Proximity { 

private String part itionAttribute = "Room"; 
public void not ifyReceived(String eventName , 
Object arg) { 

if (eventName.equals (" badgeDetected ") ) { 

onNewbadgeDetected(( 

BadgeDetectedStruct) arg); 

> 

> 
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public void subscribebadgeDetected() { 

Region regionlnfo = getSubscriptionRequest( 

partitionAttribute, getRegionLabe1s(), 
getRegionIDs()); 

PubSubMiddleware.subscribe (this , " 

badgeDetected" , regionlnfo); 

} 

protected TempStruct getprofi1e(String arg) { 

return (TempStruct) PubSubMiddleware. 
sendCommand( "getprofile" , arg, 
myDevicelnfo); 

> 

protected abstract void onNewbadgeDetected( 

BadgeDetectedStruct arg); 

protected void settempPref(UserTempPrefStruct 
newValue) { 

if (tempPref != newValue) { 
tempPref = newValue; 

PubSubMiddleware.publish ("tempPref" , 
newValue, myDevicelnfo); 

> 

> 

} 

Listing 3 — The Java abstract 

class Proximity generated from the declaration Proximity in 
the architecture specification. 


public class SimpleProximity extends Proximity { 
public void onNewbadgeDetected( 

BadgeDetectedStruct arg) { 

long timestamp = ((long) (System. 

currentTimeMillis())) * 1000000; 
UserTempPrefStruct userTempPref = new 
UserTempPrefStruct( 

arg.gettempValue(), arg.getunitOfMeasurement() 
, timestamp); 

settempPref(userTempPref); 

> 

} 

Listing 4 — The concrete implementation of the Java 
abstract class Proximity from Listing [3] written by the 
application developer. 


Concrete methods. The compilation of an architecture 
specification generates concrete methods to interact with 
other software component transparently. The generated 
concrete methods has the following two advantages: 

1. Abstracting heterogeneous interactions. To 

abstract heterogeneous interactions among software 
components, a compiler generates concrete meth¬ 
ods that takes care of heterogeneous interactions. 
For instance, a computational service processes in¬ 
put data and produces refined data to its consumers. 
The input data is either notified by other compo¬ 
nent (i.e., publish/subscribe) or requested (i.e., re¬ 
quest/response) by the service itself. Then, out¬ 
puts are published. The concrete methods for these 
interaction modes are generated in an architecture 
framework. The lines [2] to [6] of Listing [2] illus¬ 
trates these heterogeneous interactions. The Proxim¬ 
ity service has two inputs: (1) It receives badgeDe- 
tect event (Listing [2} line|4|. Our framework gen¬ 
erates the subscribebadgeDetectedO method to 


subscribe badgeDetected event (Listing [3j lines [8]- 
12). Moreover, it generates the implementation of 


notifyReceivedO method to receive the published 
events (Listing [3j lines [3][7]). (2) It requests pro¬ 

file data (Listing [2j line [5]). A sendcommandO 
method is generated to request data from other com¬ 
ponents (Listing [3j lines [l3][T5). 

2. Abstracting large scale. To address the scalable 
operations, a computational service annotates (1) its 
inputs with data interest, and (2) its placement in the 
region. Service placement and data interest jointly 
define a scope of a computational service to gather 
data. A generated architecture framework contains 
code that defines both data interest and its place¬ 
ment. For example, to get the badgeDet ected event 
notification from the BadgeReader (Listing [ 2 ] line El, 
the subscribebadgeDetectedO method (Listing |3j 
lines 8p2 ) is generated in the Proximity class. This 
method defines the data interest of a service from 
where it receives data. The value of part it ionAt¬ 
tribute (Listing [3j line [ 2 ]), which comes from the 
architecture specification (Listing [2j line [6]) , defines 
the scope of receiving data. The above constructs are 
empowered by our choice of middleware, which is a 
variation of the one presented in [42. , and enables de¬ 
livery of data across logical scopes. 


2.6. Specifying deployment concern 

This concern describes information about a target de¬ 
ployment containing various attributes of devices (such 
as location, type, attached resources) and locations where 
computational services are executed in a deployment, de¬ 
scribed using SDL (discussed in Section 2.6.1). In order 
to map computational services to devices, we present a 
mapping technique that produces a mapping from a set 
of computational services to a set of devices (discussed in 
Section 12.6.21). 


2.6.1. Srijan deployment language (SDL) 

Figure [9] illustrates deployment-specific concepts (de¬ 
fined in the conceptual model Figure [ 2 ]), specified using 
SDL. It includes device properties (such as name, type), 
regions where devices are placed, and resources that are 
hosted by devices. The resources (7Z) and regions (V) 
defined in a vocabulary become a set of values for cer¬ 
tain attributes in SDL (see the underlined words in List¬ 
ing i- SDL can be described as T v = (D). D repre¬ 
sents a set of devices. A device (d G D) can be defined 

(D region, ^resource, ^type, ^mobile)- -D region represents 

a set of device placements in terms of regions defined 
in a vocabulary. D resource is a subset of resources de¬ 
fined in a vocabulary. D type represents a set of device 
type (e.g., JavaSE device, Android device) that is used 
to pick an appropriate device driver from a device driver 
repository. D mo ^/ e represents a set of two boolean val¬ 
ues (true or false). The true value indicates a location of a 
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device is not fixed, while the false value shows a fixed loca¬ 
tion. Listing [5] illustrates a deployment specification of the 
smart building application. This snippet describes a de¬ 
vice called TemperatureMgmt-Device-1 with an attached 
TemperatureSensor and Heater, situated in building 15, 
floor 11, room 1, it is JavaSE enabled and non-mobile de¬ 
vice. 



Figure 9 — Class diagram of deployment-specific concepts 


Note that although individual listing of each device’s 
attributes appears tedious, i ) we envision that this infor¬ 
mation can be extracted from inventory logs that are main¬ 
tained for devices purchased and installed in systems, and 
ii) thanks to the separation between the deployment and 
functional concern in our approach, the same deployment 
specification can be re-used across IoT applications of a 
given application domain. 

1 devices : 

2 TemperatureHgmt-Device-1 : 

3 region : 

4 Building : 15 ; 

5 Floor : 11; 

6 Room : 1; 

7 resources : TemperatureSensor , Heater ; 

8 type : J avaSE; 

9 mobile : false ; 

10 ... 

Listing 5 — Code snippet of a deployment specification 
for the building automation domain using SDL. The language 
keywords are printed in blue, while the keywords derived from 
a vocabulary are printed underlined . 


2.6.2. Mapping 

This section presents our mapping algorithm that de¬ 
cides devices for a placement of computational services. 
It takes inputs as (1) a list of devices D defined in a de¬ 
ployment specification (see listing [ 5 ]) and (2) a list of com¬ 
putational services C defined in an architecture specifica¬ 
tion (see listing [ 2 ]). It produces a mapping of computa¬ 
tional services to a set of devices. 

We presents the mapping algorithm (see Algorithm [l]) 
that comprises two steps. The first step (lines EH con¬ 
structs the two key-value data structures from a deploy¬ 
ment specification. These two data structures are used in 


the second step. The second step (lines TopO ) selects de¬ 
vices randomly and allocates computational services to the 
selected device^] In order to give more clarity to readers, 
we describes these two steps in detail below. 

The first step (Algorithm [l] lines |4p| ) con¬ 
structs two key-value data structures regionMap 
and deviceListByRegionValue from D. The 

regionMap (line [6]) is a key-value data structure where 
regionName (e.g., Building, Floor, Room in the listing 5) 
is a key and regionValue (e.g., 15, 11, 1 in the listing 5) 
is a value. The deviceListByRegionValue (line [7]) is 
a key-value data structure where regionValue is a key 
and device (e.g., Temper atureMgmt-Device-1 in the 
listing [ 5 ]) is a value. Once, these two data structures are 
constructed, we use them for the second step (lines [To|[2 Q] ) . 

The second step (Algorithm 0 lines [T0p0| ) selects a 
device and allocates computational services to the se¬ 
lected device. To perform this task, the line [lO] re¬ 
trieves all keys (in our example Building, Floor, Room) of 
regionMap using getKeySet( ) function. For each compu¬ 
tational service (e.g., Proximity, RoomAvgTemp, RoomCon- 
troiler in listing^, the selected key from the regionMap 
is compared with a partition value of a computational 
component (line [T2| . If the value match, the next 
step (lines [T3|p~7] ) selects a device randomly and allocates 
a computational service to the selected device. 

Computational complexity. The first step (Algo¬ 
rithm^ lines[4]|9| takes 0(mr) times, where m is a number 
of devices and r is a number of region pairs in each de¬ 
specification. The second step (Algorithm [l] lines 10 


vice i 


|20| ) takes 0(nks ) times, where n is a number of region 
names (e.g., building, floor, room for the building automa¬ 
tion domain) defined in a vocabulary, k is a number of 
computational services defined in an architecture specifi¬ 
cation, and s is a number of region values specified in a 
deployment specification. Thus, total computational com¬ 
plexity of the mapping algorithm is 0{mr + nks ). 


2. 7 . Specifying platform concern 

This concern describes software components that act as 
a translator between a hardware device and an application. 
Because these components are operating system-specific, 
the device developer implements them by hand. To aid 
the device developer, we generate a vocabulary framework 
to implement platform-specific device drivers. In the fol¬ 
lowing section, we describe it in more detail. 


2.7.1. Implementing device drivers 

Leveraging the vocabulary specification, our system gen¬ 
erates a vocabulary framework to aid the device developer. 
The vocabulary framework contains concrete classes and 


10 A mapping algorithm cognizant of heterogeneity, associated with 
devices of a target deployment, is a part of our future work. See 
future work for detail. 
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Input: List D of m numbers of devices, List C of k 
numbers computational services 
Output: List mappingOutput of m numbers that contains 
assignment of C to D 

1 : Initialize regionMap key-value pair data structure 
2 : Initialize deviceListByRegionValue key-value pair da- 
structure 

3: Initialize mappingOutput key-value pair data structr: 

4: for all device in D do 

5: for all pairs ( regionName , regionValue) in device 

do 

6 : regionMap[regionName] regionValue // constru^ 

regionMap with regionN ame as key and assign 
regionValue as Value 

7: deviceListByRegionV alue\regionV alue] device 

end for 
end for 

for all regionName in regionMap.getKeySetf) do 
for all computational service in C do 

if computational service.partitionV alue () = 
regionName then 

for all regionValue in 
regionMap.getValueSet{region Name) do 
deviceList 

<— deviceListByRegionV alue.getV alueSet 
(regionValue) 

selectedDevice selectRandomDeviceFromLis fd 
eviceList) 

mappingOutput[selectedDevice] <— computationc l 


8 : 

9: 

10: 

11 : 

12: 

13: 

14: 


15: 


16: 


17 

18 

19 

20 
21 


service 

end for 
end if 
end for 
end for 

return mappingOutput 


Algorithm 1: Mapping Algorithm 


interfaces corresponding to resources defined in a vocab¬ 
ulary. A concrete class contains concrete methods for in¬ 
teracting with other software components and platform- 
specific device drivers. The interfaces are implemented 
by the device developer to write platform-specific device 
drivers. In order to enable interactions between concrete 
class and platform-specific device driver, we adopt the fac¬ 
tory design pattern [25] . This pattern provides an inter¬ 
face for a concrete class to obtain an instance of different 
platform-specific device driver implementations without 
having to know what implementation the concrete class ob¬ 
tains. Since the platform-specific device driver implemen¬ 
tation can be updated without necessitating any changes 
in code of concrete class, the factory pattern has advan¬ 
tages of encapsulation and code reuse. We illustrate this 
concept in the following paragraph with a BadgeReader 
example. 


The class diagram in Figure [lO] illustrates the con¬ 
crete class BadgeReader, the interface IBadgeReader, and 
the associations between them through the factory class 
BadgeReaderFactory. The two abstract methods of the 
IBadgeReader interface (Listing [8j lines [l]|4| ) are im¬ 
plemented in the AndroidBadgeReader class (Listing [9j 
lines HpQ ). The platform-specific implementation is ac¬ 


cessed through the BadgeReaderFactory class (Listing [7| 


9 

10 

11 

12 

13 


14 

15 

16 


lines EE5 The BadgeReaderFactory class returns an in¬ 
stance of platform-specific implementations according to 
request by the concrete method registerBadgeReader () 
the BadgeReader class (Listing [6j lines 12JT5). In the 


m 

following, we describe this class diagram with code snip¬ 
pet. 

Concrete class. For each resource declared in a vocab¬ 
ulary specification, a concrete class is generated. This 
class contains concrete methods for interacting with other 
components transparently (similar to discussed in Sec¬ 
tion 


2.5.2) and for interacting with platform-specific im¬ 
plementations. For example, the BadgeReader (Listing |6j 


lines Ip6 ) class is generated from the BadgeReader dec¬ 
laration (Listing [l] lines p4|l5| . The generated class 
contains the registerBadgeReader () method (Listing |6j 
lines T2p5 ). This method first obtains a reference of 
one (in our example Android) of platform-specific imple¬ 
mentations, then uses that reference to create an object of 
that device-specific type (Listing |6j line 13). This refer¬ 
ence is used to disseminate badgedetect event (Listing [6| 
lines 6pT). 


public class BadgeReader { 

protected void setbadgeDetected( 

BadgeDetectedStruct newValue) { 


PubSubMiddleware.publish( "badgeDetected" , 
newValue, Deviceinfo); 

} 

badgeDetected badgeDetectEvent = new 
badgeDetected() { 

public void onNewbadgeDetected( 

BadgeDetectSt resp) { 

BadgeDetectSt sBadgeDetectSt = new 

BadgeDetectSt (resp.getbadgelDQ , 
resp.gettimeStamp ()) ; 
publishbadgeDetectedEvent ( 
sBadgeDetectSt); 

> 

}; 

protected void registerBadgeReader (){ 
IBadgeReader objBadgeReader = 

BadgeReaderFactory.getBadgeReader(" 
Android") ; 

objBadgeReader.getbadgeDetected( 
badgeDetectEvent) ; 

> 

} 

Listing 6 — The Java BadgeReader class generated from the 
BadgeReader declaration in the vocabulary specification. 


Interfaces. For each resource declared in a vocabu¬ 
lary specification, interfaces are generated. Each interface 
contains synchronous and asynchronous abstract methods 
corresponding to a resource declaration. These methods 
are implemented by the device developer to write device¬ 
specific drivers. For example, our development system 
generates a vocabulary framework that contains the in¬ 
terface IBadgeReader (Listing |8j lines EEL correspond¬ 
ing to the BadgeReader (Listing [TJ lines IH3 declara¬ 
tion in the vocabulary specification. The device devel¬ 
oper programs Android-specific implementations in the 
AndroidBadgeReader class by implementing the methods 
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«interface» 

IBadgeReader 

getbadgeDetectedO BadgeDetectedStruct 
getbadgeDetected (handler: ListenerbadgeDetected) 



AndroidBadgeReader 


getbadgeDetected():BadgeDetectedStruct 
getbadgeDetected(handler: ListenerbadgeDetected) 


_ BadgeReaderFactory _ 

getBadgeReader(BadgeReaderlmpl : String) : IBadgeReader 



_ BadgeReader _ 

setbadgeDetected(newValue : BadgeDetectedStruct) 
registerBadgeReaderQ 


Figure 10 — Class diagram representing (1) the interface IBadgeReader and the implementation of two abstract methods in the 
AndroidBadgeReader class, (2) the concrete class BadgeReader that refers the AndroidBadgeReader through the BadgeReaderFactory 

factory class. 


getbadgeDetectedO and getbadgeDetected(handler) 
of the generated interface IBaderReader (Listing[9j linesjlj 
10 ). 

1 public class BadgeReaderFactory { 

2 public static IBadgeReader getBadgeReader( 

String nameBadgeReader) { 

3 

4 if(n ameBadgeReader.equals (" Android")) 

5 return new AndroidBadgeReader(); 

6 

7 if (nameBadgeReader.equals ("PC") ) 

8 return new PCBadgeReader(); 

9 } 

io } 

Listing 7 — The Java BadgeReaderFactory class. 

1 public interface IBadgeReader { 

2 public BadgeDetectedStruct getbadgeDetectedO; 

3 public void getbadgeDetected( 

ListenerbadgeDetected handler); 

4 } 

Listing 8 — The Java interface IBadgeReader generated from 
the BadgeReader declaration in the vocabulary specification. 

1 public class AndroidBadgeReader implements 

IBadgeReader { 

2 ©Override 

3 public BadgeDetectedStruct getbadgeDetectedO { 

4 // The device developer implements 

platform - specif ic code here 

5 } 

6 ©Override 

7 public void getbadgeDetected( 

ListenerbadgeDetected handler) { 

8 // The device developer implements 

platform - specif ic code here 

9 } 

10 } 

Listing 9 — The device developer writes Android-specific 
device driver of a badge reader by implementing the 
IBadgeReader interface. 


2.8. Handling evolution 

Evolution is an important aspect in IoT application de¬ 
velopment where resources and computational services are 
added, removed, or extended. To deal with these changes, 
we separate IoT application development into different 


concerns and allow an iterative development for these con¬ 
cerns. This iterative development requires only a change 
in evolved specification and reusing dependent specifica¬ 
tions/implementation in compilation process, thus reduc¬ 
ing effort to handle evolution, similar to the work in [T2] . 

Figure [Tl] illustrates evolution in the functional concern. 
It could be addition, removal, or extension of computa¬ 
tional services. A change in an architecture specification 
requires recompilation of it. The recompilation generates 
a new architecture framework and preserves the previously 
written application logic. This requires changes in the ex¬ 
isting application logic implementations manually and re¬ 
compilation of the architecture specification to generate 
new mapping files that replaces old mapping files. We now 
review main evolution cases in each development concern 
and how our approach handles them. 

Changing functionality . It refers to a change in behav¬ 
iors of an application. For example, while an application 
might be initially defined to switch on an air-conditioner 
when a temperature of room is greater than 30°C, a new 
functionality might be to open a window. This case re¬ 
quires to write a new architecture specification and appli¬ 
cation logic. 

Adding a new computational service . It refers to the 
addition of a new computational service in an architecture 
specification. The application developer implements the 
application logic of the newly added computational ser¬ 
vices. 

Removing a computational service . It refers to the 
removal of an existing computation service from an ar¬ 
chitecture specification. The application developer has 
to manually remove application logic files of the removed 
computational service. 

Adding a new input source . A new input of a com¬ 
putational service, represented as consume keyword, can 
be added. The application developer implements a gen¬ 
erated abstract method corresponding to a new input in 
application logic files. 

Removing a input source . An input can be removed 
from a computational service. In this case, the abstract 
method that implements the application logic becomes 
dead in application logic files. The IDE automatically re- 


16 

















Application 

logic 


Required 
updates in 


Application 

logic 



Application 

logic 




Newly generated 
architecture 
framework 


Deployment 

spec. 


Figure 11 — Handling evolution in the functional concern 


ports errors. The application developer has to remove this 
dead abstract method manually. 

Removing an output or command. An out¬ 
put (generate keyword) or command (command keyword) 
can be removed from an architecture specification. In this 
case code, which deals with output or command, becomes 
dead in application logic files. The application developer 
has to manually remove dead code. 


3. Components of IoTSuite 


In the following, we demonstrate the application de¬ 
velopment process, mentioned in Section |2.3[ using IoT- 
Suitj^l - a suite of tools, which is composed of different 
components, mentioned below, at each phase of applica¬ 
tion development that stakeholders can use. 


Editor. It helps stakeholders to write high-level specifica¬ 
tions, including vocabulary, architecture, and deployment 
specification with the facilities of syntax coloring and syn¬ 
tax error reporting. We use Xtexfp^for a full fledged editor 
support, similar to work in [4]. The Xtext is a frame¬ 
work for a development of domain-specific languages, and 
provides an editor with syntax coloring by writing Xtext 
grammar. 

We take an example of building automation domain vo¬ 
cabulary to demonstrate an editor support provided by 
IoTSuite, illustrated in Figure 12 The zone (T) shows the 


editor, where the domain expert writes a domain vocabu¬ 
lary. The zone (2) shows the menu bar, where the domain 
expert invokes the compiler for vocabulary to generate a 
framework, a customized architecture grammar, and de¬ 
ployment grammar. 


Compiler. The compiler parses high-level specifications 
and translates them into code that can be used by other 


components in the system. The parser module of com¬ 
piler is implemented using ANTLRp^] a well-known parser 
generator that creates parser files from grammar descrip¬ 
tions. The code generator module of compiler manages a 
repository of plug-ins. Each plug-in, defined as template 
files, is specific to a target implementation language (e.g., 
Java, Python). The key advantage of it is that it sim¬ 
plifies an implementation of a new code generator for a 
target implementation. The plug-ins are implemented us¬ 
ing StringTemplate Engine^ a Java template engine for 
generating source code or any other formatted text out¬ 
put. We build two compilers to aid stakeholders shown in 
Figure [3] (1) compiler for a vocabulary specification, and 
(2) compiler for an architecture specification. The current 
version of these compilers generate frameworks, compati¬ 
ble with Eclipse IDE. 

Mapper. The mapper produces a mapping from a set of 
computational services to a set of devices. Figure [13] il¬ 
lustrates the architecture of the mapper component. The 
parser converts high-level specifications into appropriate 
data structures that can be used by a mapping algorithm. 
The mapping algorithm produces mapping decisions into 
appropriate data structures. The code generator consumes 
the data structures and generates mapping files. Our cur¬ 
rent implementation of the mapper randomly maps com¬ 
putational services to a set of devices. However, due to 
generality of our architecture, more sophisticated mapping 
algorithm can be plugged into the mapper. 



Mapping 

files 


Figure 13 — Architecture of the mapper component in IoT¬ 
Suite. 


Linker. It combines and packs code generated by various 
11 An open source version, targeting on Android- and JavaSE - stages of compilation into packages that can be deployed 


enabled devices and MQTT middleware, is available on: https:// 


github.com/pankeshlinux/IoTSuite/wiki 

13 http://www.antlr.org/ 

http://www.eclipse.org/Xtext/ 

14 http://www.stringtemplate.org/ 
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regions : 

Building : String ; 

Floor : String; 

Room : String; 
structs : 

TempStruct 

tempValue : double; 
unitOfMeasurement : String; 

LightStruct 

lightValue : double; 
unitOfMeasurement ; String; 

BadgeDetectedStruct 
badgeID ; String; 
timeStamp : long; 

BadgeDisappearedStruct 
badgeID : String; 
timeStamp : long; 

UserPrefStruct 

tempValue: double; 
lightValue : double; 
resources: 
sensors : 

TemperatureSensor 

generate tempMeasurement : TempStruct; 

BadgeReader 

generate badgeDetected : BadgeDetectedStruct; 
generate badgeDisappeared : BadgeDisappearedStruct; 
actuators : 

Heater 

action Off(); 

action SetTemp(setTemp: TempStruct); 


Figure 12 — Editor support for writing vocabulary specification in IoTSuite. 


on devices. The output of the linker is a set of platform- 
specific projects for devices, specified in the deployment 
specification. These projects are not binaries. They need 
to be compiled, which can be done by any device-specific 
compiler designed for the target platform. The current 
version of the linker generates Java source packages for 
Android and JavaSE platform. Figure [14] illustrates pack¬ 
ages for 3 target devices (2 packages for JavaSE devices 
and 1 for Android device), which can be imported into 

Date modified Type 

5/16/2014 5:43 PM File folder 

5/16/2014 5:43 PM File folder 

5/16/2014 5:43 PM File folder 


' An Android Project to 
deploy on Device - D3 


Eclipse IDE. 

Name 


\ 

A JavaSE Project to 
deploy on Device D2 



Figure 14 — Packages for target devices compatible with 
Eclipse IDE 

Runtime system . The main responsibility of the runtime 
system is a distributed execution of IoT applications. It is 
composed of three parts: (1) middleware : It runs on each 
individual device and provides a support for executing dis¬ 
tributed tasks. (2) wrapper : It plugs packages, generated 
by the linker module, and middleware. (3) support library : 
It separates packages, produced by the linker component, 
and underlying middleware by providing interfaces that 
are implemented by each wrapper. The integration of a 


new middleware into IoTSuite consists of an implementa¬ 
tion of the following interfaces, specified by the support 
library, in the wrapper. 

• publish(). It is an interface for publishing data from 
a sender. The definition of this interface contains: an 
event name (e.g., temperature), event data (e.g., a 
temperature value, Celsius), and publisher’s informa¬ 
tion such as location. 

• subscribe(). It is an interface for receiving event 
notifications. An interest of events is expressed by 
sending a subscription request, which contains: a 
event name (e.g., temperature), information for fil¬ 
tering events such as regions of interest (e.g., a 
RoomAvgTemp component wants to receive events 
only from a current room), and subscriber’s informa¬ 
tion. 

• commandO. It is an interface for triggering an ac¬ 
tion of an actuator. A command contains: a com¬ 
mand name (e.g., switch-on heater), command param¬ 
eters (e.g., set temperature of heater to 30°C), and a 
sender’s information. 

• request-response (). It is an interface for requesting 
data from a requester. In reply, a receiver sends a re¬ 
sponse. A request contains a request name (e.g., give 
profile information), request parameters (e.g., give 
profile of person with identification 12), and informa¬ 
tion about the requester. 

The current implementation of IoTSuite uses the 
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MQTT0 middleware, which enables interactions among 
Android devices and JavaSE enabled devices. 


4. Evaluation 

The goal of this section is to describe how well the pro¬ 
posed approach addresses our aim in a quantitative man¬ 
ner. Unfortunately, the goal is very vague because qual¬ 
ity measures are not well-defined and they do not provide 
a clear procedural method to evaluate development ap¬ 
proaches in general. We explore development effort, which 
indicates effort required to create an application, that is 
vital for the productivity of stakeholders m- 

To evaluate our approach we consider two representative 
IoT applications: (1) the smart building application de¬ 
scribed in Section m and (2) a fire detection application, 
which aims to detect fire by analyzing data from smoke 
and temperature sensors. When fire occurs, residences are 
notified on their smart phones by an installed application. 
Additionally, residents of the building and neighborhood 
are informed through a set of alarms. Figure [15] shows 
the architecture of the fire detection application. A fire 
state is computed based on a current average temperature 
value and smoke presence by a local fire state service (i.e., 
roomFireState) deployed per room, then a state is sent 
to a service (i.e., f loorFireState) deployed per floor, and 
finally a computational service (i.e., buildingFireCon- 
troller) decides whether alarms should be activated and 
users should be notified or not. 

4-1. Development effort 

In order to measure effort to develop an application, we 
evaluate a percentage of a total number of lines of code 
generated by our approach and effort to develop an ap¬ 
plication involving a large number of devices using our 
approach, we have implemented two IoT applications dis¬ 
cussed in the previous Section using our approach. These 
applications are implemented independently. We did not 
reuse specifications and implementations of one applica¬ 
tion in other application. We deployed the two applica¬ 
tions on 10 simulated devices running on top of a middle¬ 
ware that simulates network on a single PC dedicated to 
the evaluation. 

We measured development effort using Eclipse 
EclEmma 2.2.1 plug-in. This tool counts actual Java 
statement as lines of code and does not consider blank 
lines or lines with comments. Our measurements reveal 
that more than 82% of the total number of lines of code 
is generated in two applications (see Table [ 2 ]). 

The measure of lines of code is only useful if the gen¬ 
erated code is actually executed. We measured code cov¬ 
erage of the generated programming frameworks of two 
applications (see Table [ 2 ]) using the EclEmmsp^l Eclipse 


15 http://mqtt.org/ 

16 http://www.eclemma.org/ 



Figure 15 — Architecture of the fire detection application, 
similar to work in m 


plug-in. Our measures show that more than 90% of gen¬ 
erated code is actually executed, the other portion being 
error-handling code for errors that did not happen during 
the experiment. This high value indicates that most of the 
execution is spent in generated code and that, indeed, our 
approach reduces development effort by generating useful 
code. 

The above experiment was conducted for 10 simulated 
devices. It does not demonstrate development effort using 
our approach for a large number of devices. Therefore, 
the primary aim of this experiment is to evaluate effort 
to develop an IoT application involving a large number 
of devices. In order to achieve the above aim, we have 
developed the smart building application on a set of sim¬ 
ulated device running on top of the middleware dedicated 
to the evaluation. The assessments were conducted over 
an increasing number of devices. The first development ef¬ 
fort assessment was conducted on 10 devices instrumented 
with heterogeneous sensors, actuators, storages, and user 
interfaces. In the next subsequent assessments, we kept in¬ 
creasing the number of devices equipped with sensors and 
actuators. In each assessment, we have measured lines of 
code to specify vocabulary, architecture, and deployment, 
application logic, and device drivers. Table [3] illustrates 
the assessment results containing a number of devices in¬ 
volved in the experiment and hand-written lines of code 
to develop the smart building application. 

In Table [3J we have noted the following two observations 
and their reasons: 

1. As the number of devices increases, lines of code 
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Application 

Name 

Vocab 

Spec. 

Handwritten (lines 

of code) 

Device 

driver 

App. 

logic 

Generated (lines 

of code) 

Vocab. 

fram. 

% of Generated code 

generated 

Code coverage 

i-ll UIl. 

Spec. 

-L^epiuy. 

Spec. 

(devices=10) 

IVicippiIlg 

code 

UIll. 

fram. 

handwritten-\-generated 

Smart building 

41 

28 

81 

98 

131 

561 

408 

757 

81.99% 

92.22 

Fire detection 

27 

21 

81 

53 

72 

528 

292 

476 

83.61% 

90.38 


Table 2 — Lines of code in smart building and fire detection applications 


Number of 
devices 

Vocab 

Spec. 

Handwritten (lines of code) 

Arch. Deploy. Device 

Spec. Spec. driver 

App. 

logic 

10 

41 

28 

81 

98 

131 

34 

41 

28 

273 

98 

131 

50 

41 

28 

401 

98 

131 

62 

41 

28 

497 

98 

131 

86 

41 

28 

689 

98 

131 

110 

41 

28 

881 

98 

131 

200 

41 

28 

1601 

98 

131 

300 

41 

28 

2401 

98 

131 

350 

41 

28 

2801 

98 

131 

500 

41 

28 

4001 

98 

131 

Table 3 - 

Number of devices 

involved in 

the development 


effort assessment and hand-written lines of code to develop the 
smart building application. 


for vocabulary and architecture specification, device 
drivers, and application logic remain constant for a de¬ 
ployment consisting a large number of devices. The 
reason is that our approach provides the ability to 
specify an application at a global level rather than 
individual nodes. 

2. As the number of devices increases, lines of code for a 
deployment specification increase. The reason is that 
the network manager specifies each device individu¬ 
ally in the deployment specification. This is a limi¬ 
tation of SDL. Our future work will be to investigate 
how a deployment specification can be expressed in 
a concise and flexible way for a network with a large 
number of devices. We believe that the use of regu¬ 
lar expressions is a possible technique to address this 
problem. 


5. Related work 

This Section focuses on existing works in literature that 
would address the research challenges discussed in Sec¬ 
tion [T2] As stated earlier, while the application develop¬ 
ment life-cycle has been discussed in general in the soft¬ 
ware engineering domain, a similar structured approach is 


largely lacking in the IoT for the development of Sense- 
Computer-Control (SCC) [63, p. 97] applications. Con¬ 
sequently, in this Section we present existing approaches 
geared towards the IoT, but also its precursor fields of Per¬ 
vasive Computing and Wireless Sensor Networking. These 
are mature fields, with several excellent surveys available 
on programming models [62, 43 a and middleware [33 . 

We organize this Section based on the perspective of 
the system provided to the stakeholders by the various 
approaches. Section |5T] presents the node-level program¬ 
ming approaches, where the developer has significant con¬ 
trol over the actions of each device in the system, which 
comes at the cost of complexity. Section |5.2| summa¬ 
rizes approaches that aim to abstract the entire (sens¬ 
ing) system as a database on which one can run queries. 
Section |5.3| presents the evolution of these approaches to 
macroprogramming inspired by general-purpose program¬ 
ming languages, where abstractions are provided to specify 
high-level collaborative behaviors at the system-level while 


hiding low-level details from stakeholders. Section 5.4 


then describes the macroprogramming approaches more 
grounded in model-driven development techniques, which 
aim to provide a cleaner separation of concerns during the 
application development process. We summarize all these 
approaches in Table [4] 


5.1 . Node-centric programming 

In the following, we present systems that adopt the 
node-centric approach. 

In the pervasive computing domain, Olympus [53, is 
a programming model on top of Gaia [54] - a dis¬ 
tributed middleware infrastructure for pervasive environ¬ 
ments. Stakeholders write a C++ program that consists 
of a high-level description about active space entities (in¬ 
cluding service, applications, devices, physical objects, and 
locations) and common active operations (e.g., switching 
devices on/, starting/stopping applications). The Olym¬ 
pus framework takes care of resolving high-level descrip¬ 
tion based on properties specified by stakeholders. While 
this approach certainly simplifies the SCC application de¬ 
velopment involving heterogeneous devices, stakeholders 
have to write a lot of code to interface hardware and soft¬ 
ware components, as well as to interface software compo¬ 
nents and its interactions with a distributed system. This 
makes it tedious to develop applications involving a large 
number of devices. 
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The Context toolkit [13 [56] simplifies the context- 
aware application development on top of heterogeneous 
data sources by providing three architectural components, 
namely, widgets, interpreters, and aggregators. These 
components separate application semantics from platform- 
specific code. For example, an application does not have 
to be modified if an Android-specific sensor is used rather 
than a Sun SPOT sensor. It means stakeholders can treat 
a widget in a similar fashion and do not have to deal with 
differences among platform-specific code. Although con¬ 
text toolkit provides support for acquiring the context data 
from the heterogeneous sensors, it does not support actu¬ 
ation that is an essential part of IoT applications. 

Henricksen et al. [321 EH propose a middleware and a 
programming framework to gather, manage, and dissemi¬ 
nate context to applications. This work introduces context 
modeling concepts, namely, context modeling languages, 
situation abstraction; and preference and branching mod¬ 
els. This work presents a software engineering process that 
can be used in conjunction with the specified concepts. 
However, the clear separation of roles among the various 
stakeholders is missing. Moreover, this framework limits 
itself to context gathering applications, thus not providing 
the actuation support that is important for IoT application 
development. 

Physical-Virtual mashup. As indicated by its name, 
it connects web services from both the physical and vir¬ 
tual world through visual constructs directly from web 
browsers. The embedded device runs tiny web servers M 
to answer HTTP queries from users for checking or chang¬ 
ing the state of a device. For instance, users may want to 
see temperature of different places on map. Under such 
requirements, stakeholders can use the mashup to connect 
physical services such as temperature sensors and virtual 
services such as Google map. Many mashup prototypes 
have been developed that include both the physical and 
virtual services [8, 28 , 13 , 26, 3d • The mashup editor usu¬ 
ally provides visual components representing web service 
and operations (such as add, filter) that stakeholders need 
to connect together to program an application. The frame¬ 
work takes care of resolving these visual components based 
on properties specified by stakeholders and produces code 
to interface software components and distributed system. 
The main advantage of this mashup approach is that any 
service, either physical or virtual, can be mashed-up if they 
follow the standards (e.g., REST). The Physical-Virtual 
mashup significantly lowers the barrier of the application 
development. However, stakeholders have to manage a 
potentially large graph for an application involving a large 
number of entities. This makes it difficult to develop ap¬ 
plications containing a large number of entities. 

5.2. Database approach 

In TinyDB [39^ and Cougar [68] systems, an SQL-like 
query is submitted to a WSN. On receiving a query, the 
system collects data from the individual device, filters it, 


and sends it to the base station. They provide a suit¬ 
able interface for data collection in a network with a large 
number of devices. However, they do not offer much flex¬ 
ibility for introducing the application logic. For exam¬ 
ple, stakeholders require extensive modifications in the 
TinyDB parser and query engine to implement new query 
operators. 

The work on SINA (Sensor Information Networking Ar¬ 
chitecture) [59] overcomes this limitation on specification 
of custom operators by introducing an imperative language 
with an SQL query. In SINA, stakeholders can embed 
a script written in Sensor Querying and Tasking Lan¬ 
guage (SQTL) [35] in the SQL query. By this hybrid ap¬ 
proach, stakeholders can perform more collaborative tasks 
than what SQL in TinyDB and Cougar can describe. 

The TinyDB, Cougar, and SINA systems are largely lim¬ 
ited to homogeneous devices. The IrisNet (Internet-Scale 
Resource-Intensive Sensor Network) [27] allows stakehold¬ 
ers to query a large number of distributed heterogeneous 
devices. For example, Internet-connected PCs source sen¬ 
sor feeds and cooperate to answer queries. Similar to the 
other database approaches, stakeholders view the sensing 
network as a single unit that supports a high-level query 
in XML. This system provides a suitable interface for data 
collection from a large number of different types of de¬ 
vices. However, it does not offer flexibility for introducing 
the application logic, similar to TinyDB and Cougar. 

Semantic Streams m allows stakeholders to pose a 
declarative query over semantic interpretations of sensor 
data. For example, instead of querying raw magnetome¬ 
ter data, stakeholders query whether a vehicle is a car or 
truck. The system infers this query and decides sensor 
data to use to infer the type of vehicle. The main bene¬ 
fit of using this system is that it allows people, with less 
technical background to query the network with heteroge¬ 
neous devices. However, it presents a centralized approach 
for sensor data collection that limits its applicability for 
handling a network with a large number of devices. 

Standardized protocols-based systems. A number 
of systems have been proposed to expose functionality of 
devices accessible through standardized protocols without 
having worry about the heterogeneity of underlying infras¬ 
tructure m ■ They logically view sensing devices (e.g., mo¬ 
tion sensor, temperature sensor, door and window sensor) 
as service providers for applications and provide abstrac¬ 
tions usually through a set of services. We discuss these 
examples below. 

Priyantha et al. [52] present an approach based on 
SOAP |9j to enable an evolutionary WSN where additional 
devices may be added after the initial deployment. To sup¬ 
port such a system, this approach has adopted two fea¬ 
tures. (1) structured data: the data generated by sensing 
devices are represented in a XML format for that may be 
understood by any application. (2) structured function¬ 
ality: the functionality of a sensing device is exposed by 
Web Service Description Language (WSDL) [15]. While 
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this system addresses the evolution issue in a target de¬ 
ployment, the authors do not demonstrate the evolution 
scenarios such as a change in functionality of an applica¬ 
tion, technological advances in deployment devices. 

A number of approaches based on REST |22j have been 
proposed to overcome the resource needs and complexity 
of SOAP-based web services for sensing and actuating de¬ 
vices. Tiny REST [38] is one of first attempts to overcome 
these limitations. It uses the HTTP-based REST architec¬ 
ture to access a state of sensing and actuating devices. The 
Tiny REST gateway maps the HTTP request to Tiny OS 
messages and allows stakeholders to access sensing and 
actuating devices from their applications. The aim of this 
system is to make services available through standardized 
REST without having to worry about the heterogeneity of 
the underlying infrastructure; that said, it suffers from a 
centralized structure similar to TinySOA. 

5.3. Macroprogramming languages 

In the following, we present macroprogramming lan¬ 
guages for IoT application development, which are 
grounded in traditional general purpose programming lan¬ 
guages (whether imperative or functional) in order to pro¬ 
vide developers with familiar abstractions. 

Kairos [29] allows stakeholders to program an applica¬ 
tion in a Python-based language. The Kairos develop¬ 
ers write a centralized program of a whole application. 
Then, the pre-processor divides the program into subpro¬ 
grams, and later its compiler compiles it into binary code 
containing code for accessing local and remote variables. 
Thus, this binary code allows stakeholders to program dis¬ 
tributed sensor network applications. Although Kairos 
makes the development task easier for stakeholders, it tar¬ 
gets homogeneous network where each device executes the 
same application. 

Regiment [44] provides a high-level programming lan¬ 
guage based on Haskell to describe an application as a set 
of spatially distributed data streams. This system pro¬ 
vides primitives that facilitate processing data, manipu¬ 
lating regions, and aggregating data across regions. The 
written program is compiled down to an intermediate to¬ 
ken machine language that passes information over a span¬ 
ning tree constructed across the WSN. In contrast to the 
database approaches, this approach provides greater flex¬ 
ibility to stakeholders when it comes to the application 
logic. However, the regiment program collects data to a 
single base station. It means that the flexibility for any- 
to-any device collaboration for reducing scale is difficult. 

MacroLab |34j offers a vector programming abstraction 
similar to Matlab for applications involving both sensing 
and actuation. Stakeholders write a single program for 
an entire application using Matlab like operations such as 
addition, find, and max. The written macroprogram is 
passed to the MacroLab decomposer that generates mul¬ 
tiple decompositions of the program. Each decomposition 
is analyzed by the cost analyzer that calculates the cost of 
each decomposition with respect to a cost profile (provided 


by stakeholders) of a target deployment. After choosing a 
best decomposition by the cost analyzer, it is passed to 
the compiler that converts the decomposition into a bi¬ 
nary executable. The main benefit is that it offers flex¬ 
ibility of decomposing code according to cost profiles of 
the target platform. While this system certainly separates 
the deployment aspect and functionality of an application, 
this approach remains general purpose and provides little 
guidance to stakeholders about the application domain. 

5.4. MDD approach 

A number of model-driven approaches have been pro¬ 
posed to make IoT application development easy, de¬ 
scribed below. 

PervML [58] allows stakeholders to specify pervasive ap¬ 
plications at a high-level of abstraction using a set of mod¬ 
els. This system raises the level of abstraction in program 
specification, and code generators produce code from these 
specifications. Nevertheless, it adopts generic UML nota¬ 
tions to describe them, thus provides little guidance to 
stakeholders about the specific application domain. In ad¬ 
dition to this, the main focus of this work is to address the 
heterogeneity associated with pervasive computing appli¬ 
cations, and the consideration of a large number of devices 
in an application is missing. PervML integrates the map¬ 
ping process at the deployment phase. However, stake¬ 
holders have to link the application code and configure 
device drivers manually. This manual work in the deploy¬ 
ment phase is not suitable for IoT applications involving 
a large number of devices. Moreover, the separation be¬ 
tween deployment and domain-specific features are miss¬ 
ing. These limitations would restrict PervML to a certain 
level. 

DiaSuite m is a suite of tools to develop pervasive 
computing applications. It combines design languages and 
covers application development life-cycle. The design lan¬ 
guage defines both a taxonomy of an application domain 
and an application architecture. Stakeholders define enti¬ 
ties in a high-level manner to abstract heterogeneity. How¬ 
ever, the consideration of a large number of devices in an 
application is largely missing. Moreover, the application 
deployment for a large number of heterogeneous devices us¬ 
ing this approach is difficult because stakeholders require 
manual effort (e.g., mapping of computational services to 
devices). 

ATaG [50], which is a WSN is a macroprogramming 
framework to develop SCC applications. ATaG presents 
a compilation framework that translates a program, con¬ 
taining abstract notations, into executable node-level pro¬ 
grams. Moreover, it tackles the issue of scale reasonably 
well. The ATaG linker and mapper modules support the 
application deployment phase by producing device-specific 
code to result in a distributed software system collabo- 
ratively hosted by individual devices, thus providing au¬ 
tomation at deployment phase. Nevertheless, the clear 
separation of roles among the various stakeholders in the 
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application development, as well as the focus on hetero¬ 
geneity among the constituent devices are largely missing. 
Moreover, the ATaG program notations remains general 
purpose and provides little guidance to stakeholders about 
the application domain. 

RuleCaster introduces an engineering method to 

provide support for SCC applications, as well as evolution¬ 
ary changes in the application development. The Rule- 
Caster programming model is based on a logical partition¬ 
ing of the network into spatial regions. The RuleCaster 
compiler takes as input the application program contain¬ 
ing rules and a network model that describes device loca¬ 
tions and its capabilities. Then, it maps processing tasks 
to devices. Similar to ATaG, this system handles the scale 
issue reasonably well by partitioning the network into sev¬ 
eral spatial regions. Moreover, it supports automation at 
the deployment phase by mapping computational compo¬ 
nents to devices. However, the clear separation of roles 
among the various stakeholders, support for application 
domain, as well as the focus on heterogeneity among the 
constituent devices are missing. 

Pantagruel m is a visual approach dedicated to the de¬ 
velopment of home automation applications. The Panta¬ 
gruel application development consists of three steps: (1) 
specification of taxonomy to define entities of the home au¬ 
tomation domain (e.g., temperature sensor, alarm, door, 
smoke detector, etc.), (2) specification of rules to orches¬ 
trate these entities using the Pantagruel visual language, 
and (3) compilation of the taxonomy and orchestration 
rules to generate a programming framework. The nov¬ 
elty of this approach is that the orchestration rules are 
customized with respect to entities defined in the taxon¬ 
omy. While this system reduces the requirement of hav¬ 
ing domain-specific knowledge for other stakeholders, the 
clear separation of different development concerns, support 
for large scale, automation both at the development and 
deployment phase are largely missing. These limitations 
make it difficult to use for IoT application development. 

6. Conclusion 

This paper presents a development methodology for IoT 
application development, based on techniques presented 
in the domains of sensor network macroprogramming and 
model-driven development. It separates IoT application 
development into different concerns and integrates a set 
of high-level languages to specify them. This approach is 
supported by automation techniques at different phases of 
IoT application development and allows an iterative de¬ 
velopment to handle evolutions in different concerns. Our 
evaluation based on two realistic IoT applications shows 
that our approach generates a significant percentage of the 
total application code, drastically reduces development ef¬ 
fort for IoT applications involving a large number of de¬ 
vices. Our approach addresses the challenges discussed in 
Section [L2| in the following manner: 


Lack of division of roles. Our approach identifies roles 
of each stakeholder and separates them according to their 
skills. The clear identification of expectations and spe¬ 
cialized skills of each stakeholder helps them to play their 
part effectively, thus promoting a suitable division of work 
among stakeholders involved in IoT application develop¬ 
ment. 

Heterogeneity. SAL and SVL provide abstractions to 
specify different types of devices, as well as heterogeneous 
interaction modes in a high-level manner. Further, high- 
level specifications written using SAL and SVL are com¬ 
piled to a programming framework that (1) abstracts het¬ 
erogeneous interactions among software components and 
(2) aids the device developers to write code for different 
platform-specific implementations. 

Scale. SAL allows the software designer to express his re¬ 
quirements in a compact manner regardless of the scale of 
a system. Moreover, it offers scope constructs to facilitate 
scalable operations within an application. They reduce 
scale by enabling hierarchical clustering in an application. 
To do so, these constructs group devices to form a clus¬ 
ter based on their spatial relationship (e.g., “devices are in 
room#l”). Within a cluster, a cluster head is placed to 
receive and process data from its cluster of interest. The 
grouping could be recursively applied to form a hierarchy 
of clusters. The scale issue is thus handled, thanks to the 
use of a middleware that supports logical scopes and re¬ 
gions. 

Different life cycle phases. Our approach is supported 
by code generation, task-mapping, and linking techniques. 
These techniques together provide automation at different 
life cycle phases. At the development phase, the code gen¬ 
erator produces (1) an architecture framework that allows 
the application developer to focus on the application logic 
by producing code that hide low-level interaction details 
and (2) a vocabulary framework to aid the device devel¬ 
oper to implement platform-specific device drivers. At the 
deployment phase, the mapping and linking together pro¬ 
duce device-specific code to result in a distributed software 
system collaboratively hosted by individual devices. To 
support maintenance phase, our approach separates IoT 
application development into different concerns and allows 
an iterative development, supported by the automation 
techniques. 

7. Future work 

This paper addresses the challenges, presented by the 
steps involved in IoT application development, and pre¬ 
pares a foundation for our future research work. Our fu¬ 
ture work will proceed in the following complementary di¬ 
rections, discussed below. 

Mapping algorithms cognizant of heterogeneity. 

While the notion of region labels is able to reasonably 
tackle the issue of scale at an abstraction level, the prob¬ 
lem of heterogeneity among the devices still remains. We 
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Existing Approaches 


Division of roles 

Hetro. 

Scale 

Life-cycle phases 







Development 

phase 

Deployment 

phase 

Maintenance 

phase 


Context Toolkit (2001) 

X 


X 

X 

X 


Node-centric 

Olympus 1531 (2005) 

X 


X 

X 

X 

X 

Programming 

Henricksen et al. [5] (2010) 

X 


X 


X 

X 


Dominique et al. 1281 (2010) 

X 

V 

X 

- 

X 

~ 


TinyDB [39] (2000) 

X 

X 


Not clear 

X 

X 


IrisNet [27] (2000) 

X 

- 

- 

Not clear 

X 

X 

Database 

SINA [59] (2000) 

X 

X 

V 

Not clear 

X 

X 

Approach 

TinyREST [38] (2005) 

X 

V 

X 

X 

X 



Semantic 

Streams 1671 (2006) 

X 


X 


X 

X 


Priyantha et al. [52] (2008) 

X 

V 

X 

X 

X 

~ 

Macroprogramming 

Kairos 1291 (2005) 

X 

X 

V 



X 

Languages 

Regiment |44| (2007) 

X 

X 

~ 



X 


MacroLab [34] (2008) 

X 

X 

V 





RuleCaster [7] (2007) 

X 

X 

V 




Mo del-driven 

Pantagruel 1191 (2009) 



X 


X 


Development 

PervML [58] (2010) 


V 

X 


- 



DiaSuite ^] (2011) 


V 

X 


X 



ATaG [50] (2011) 

X 

- 

V 

- 

V 



Table 4 — Comparison of existing approaches, yj - Supported, x - No supported, ~ - No adequately supported. 


will provide rich abstractions to express both the proper¬ 
ties of the devices (e.g., processing and storage capacity, 
networks it is attached to, as well as monetary cost of host¬ 
ing a computational service), as well as the requirements 
from stakeholders regarding the preferred placement of the 
computational services of the applications. These will then 
be used to guide the design of algorithms for efficient map¬ 
ping (and possibly migration) of computational services on 
devices. 

Developing concise notion for SDL . In the current 
version of SDL, the network manager is forced to spec¬ 
ify the detail of each device individually. This approach 
works reasonably well in a target deployment with a small 
number of devices. However, it may be time-consuming 
and error-prone for a target deployment consisting of hun¬ 
dreds to thousands of devices. Our future work will be 
to investigate how the deployment specification can be ex¬ 
pressed in a concise and flexible way for a network with a 
large number of device. We believe that the use of regular 
expressions is a possible technique to address this problem. 

Testing support for IoT application development. 

Our near term future work will be to provide support for 
the testing phase. A key advantage of testing is that it em¬ 
ulates the execution of an application before deployment so 
as to identify possible conflicts, thus reducing application 
debugging effort. The support will be provided by inte¬ 


grating an open source simulator. This simulator will en¬ 
able transparent testing of IoT applications in a simulated 
physical environment. Moreover, we expect to enable the 
simulation of a hybrid environment, combining both real 
and physical entities. Currently, we are investigating open 
source simulators for IoT applications. We see Siafrp^] as 
a possible candidate due to its open source and thorough 
documentation. 

Run-time adaptation in IoT applications. Even 
though our approach addresses the challenges posed by 
evolutionary changes in target deployments and appli¬ 
cation requirements, stakeholders have to still recompile 
the updated code. This is common practice in a single 
PC-based development environment, where recompilation 
is generally necessary to integrate changes. However, it 
would be very interesting to investigate how changes can 
be injected into the running application that would adapt 
itself accordingly. For instance, when a new device is 
added into the target deployment, an IoT application can 
autonomously include a new device and assign a task that 
contributes to the execution of the currently running ap¬ 
plication. 


17 http://siafusimulator.org/ 
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